Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

Documentation: workspace.open( ) with no URI #6005

Merged
merged 2 commits into from Apr 9, 2015
Merged

Documentation: workspace.open( ) with no URI #6005

merged 2 commits into from Apr 9, 2015

Conversation

vegar
Copy link
Contributor

@vegar vegar commented Mar 17, 2015

I just learned that calling open on workspace without specifying an uri is the way to go for getting a new tab with a new document.

I can't find anything about this in either the docs or the api documentation.

Should uri be marked optional, like the options params? And should it be added a line stating that no uri opens a blank editor?

(and there's an extra a in the title..)

I just learned that [calling open on workspace](https://discuss.atom.io/t/how-can-we-help-you-write-packages/4268/67) without specifying an uri is the way to go for getting a new tab with a new document. 

I can't find anything about this in either the docs or the [api documentation.](https://atom.io/docs/api/v0.187.0/Workspace#instance-open)

Should `uri` be marked optional, like the `options` params? And should it be added a line stating that no uri opens a blank editor?

(and there's an extra `a` in the title..)
@izuzak
Copy link
Contributor

izuzak commented Mar 18, 2015

This makes sense to me. What do you think, @nathansobo -- is it 🆒 to document this behavior?

@nathansobo
Copy link
Contributor

Yeah, documenting that would be great.

#
# * `uri` A {String} containing a URI.
# Essential: Open a given URI in Atom asynchronously.
# If no URI is given, or URI does not resolve to an existing file,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps instead of saying:

or URI does not resolve to an existing file,

we could say something like

or URI is not already open in an existing pane item

because URIs are used to reference and open more than files. For example, atom.workspace.open("atom://config") can be used to open the Settings View. What do you think, @vegar?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First: I have been looking at atom for three spare nights now. I have very little knowledge of how it works.

What I found, was that if we have atom.workspace.open("file_not_on_disk.txt"), we get a new editor/document where the filename is initalized to the URI, so if you hit save you wan't be prompted for a filename - it will just save the file in the root of the current project.
If you do not have a project open, you will still get a new document, but the document will not get the filename specified. It will get 'untitled'.

So the proposed text .., or URI does not resolve to an existingn file, ... was supposed to capture some of this behavior. Not a very clear formulation I guess.. 😳 ..but that was it's intent.

I think maybe your proposed change will document yet another behavior that I was unaware of. Maybe it should be added as a separate bullet point? (The documentation guidelines may have an opinion on how behavior should be listed?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I found, was that if we have atom.workspace.open("file_not_on_disk.txt"), we get a new editor/document where the filename is initalized to the URI, so if you hit save you wan't be prompted for a filename - it will just save the file in the root of the current project.
If you do not have a project open, you will still get a new document, but the document will not get the filename specified. It will get 'untitled'.

@vegar I'd skip documenting this stuff around untitled filenames for now, especially not here since you're referring to something that will happen on save, and the user might not even save the file. I think my proposed change reflects the behavior related to opening, which is the method we are documenting here. Sound good?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also cc @nathansobo in case he has different opinions on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vegar Just to make sure I understand -- does that 👍 mean that you want to update the PR to clarify the text based on my above suggestion? https://github.com/atom/atom/pull/6005/files#r26837887 I'm still in favor of making that update.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was me agreeing to not documenting all the save-related behavior here.

About your initial suggesting: replacing

or URI does not resolve to an existing file,

with

or URI is not already open in an existing pane item

I'm not sure what's best.

Your suggestion states that if the uri is already open, it wan't open again, but is that true? Or is that dependent on how the open handler are implemented? (Cause in a small test project I have, I get multiple tabs with the same uri... ..not that I wanted to, but I can't find out how to prevent it...)

My suggestion states that if the uri is a file uri but the file doesn't exist, you will get a new text editor.

So... What about

Essential: Opens a given URI in Atom asynchronously, if it's not already open.

If no URI is given, or URI is a filepath and the file does not exist, a new empty text editor is created.

or

..., or URI is to a file that does not exist, ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong opinions here, as long as we're accurate. I do like ensuring our language makes clear that URIs don't always correspond to paths on disk.

@izuzak izuzak merged commit 4cf34cc into atom:master Apr 9, 2015
izuzak added a commit that referenced this pull request Apr 9, 2015
Documentation: workspace.open( ) with no URI
@izuzak
Copy link
Contributor

izuzak commented Apr 9, 2015

This is merged now, I just made a minor clarification in b8fb2f4. Thanks again for this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants